<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
    <head>
        <title>RVM : VM Conventions</title>
	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
    </head>

    <body>
	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
		    <tr>
			    <td valign="top" class="pagebody">
				    <div class="pageheader">
					    <span class="pagetitle">
                            RVM : VM Conventions
                                                    </span>
				    </div>
				    <div class="pagesubheading">
					    This page last changed on Jul 02, 2008 by <font color="#0050B2">dgrove</font>.
				    </div>

				    <h2><a name="VMConventions-AIX%2FPowerPCVMConventions"></a>AIX/PowerPC VM Conventions</h2>

<p>This section describes register, stack, and calling conventions that apply to Jikes RVM on AIX/PowerPC<a href="http://docs.codehaus.org/display/RVM/Trademarks" title="Trademarks">™</a>.</p>

<p>Stackframe layout and calling conventions may evolve as our understanding of Jikes RVM's performance improves. Where possible, API's should be used to protect code against such changes. In particular, we may move to the AIX<a href="http://docs.codehaus.org/display/RVM/Trademarks" title="Trademarks">™</a> conventions at a later date. Where code differs from the AIX conventions, it should be marked with a comment to that effect containing the string "AIX".<br/>
Register conventions</p>

<h3><a name="VMConventions-Registers%28generalpurpose%2Cgp%2Candfloatingpoint%2Cfp%29canberoughlycategorizedintofourtypes%3A"></a>Registers (general purpose, gp, and floating point, fp) can be roughly categorized into four types:</h3>

<ul>
	<li><b>Scratch:</b> Needed for method prologue/epilogue. Can be used by compiler between calls.</li>
	<li><b>Dedicated:</b> Reserved registers with known contents:
	<ul>
		<li><b>JTOC</b> &#45; Jikes RVM Table Of Contents. Globally accessible data: constants, static fields and methods.</li>
		<li><b>FP</b> &#45; Frame Pointer Current stack frame (thread specific).</li>
		<li><b>PR</b> &#45; Processor register. An object representing the current virtual processor (the one executing on the CPU containing these registers). A field in this object contains a reference to the object representing the RVMThread being executed.</li>
	</ul>
	</li>
	<li><b>Volatile ("caller save", or "parameter"):</b> Like scratch registers, these can be used by the compiler as temporaries, but they are not preserved across calls. Volatile registers differ from scratch registers in that volatiles can be used to pass parameters and result(s) to and from methods.</li>
	<li><b>Nonvolatile ("callee save", or "preserved"):</b> These can be used (and are preserved across calls), but they must be saved on method entry and restored at method exit. Highest numbered registers are to be used first. (At least initially, nonvolatile registers will not be used to pass parameters.)</li>
	<li><b>Condition Register's 4-bit fields:</b> We follow the AIX conventions to minimize cost in JNI transitions between C and Java code. The baseline compiler only uses CR0. The opt compiler allocates CR0, CR1, CR5 and CR6 and reserves CR7 for use in yieldpoints. None of the compilers use CR2, CR3, or CR4 to avoid saving/restoring condition registers when doing a JNI transition from C to Java code.
	<ul>
		<li><b>CR0, CR1, CR5, CR6, CR7</b> &#45; volatile</li>
		<li><b>CR2, CR3, CR4</b> &#45; non-volatile</li>
	</ul>
	</li>
</ul>


<h3><a name="VMConventions-Stackconventions"></a>Stack conventions</h3>

<p>Stacks grow from high memory to low memory. The layout of the stackframe appears in a block comment in <tt>ppc/StackframeLayoutConstants.java</tt>.</p>

<h3><a name="VMConventions-CallingConventions"></a>Calling Conventions</h3>


<h4><a name="VMConventions-Parameters"></a>Parameters</h4>

<p>All parameters (that fit) are passed in VOLATILE registers. Object reference and int parameters (or results) consume one GP register; long parameters, two gp registers (low-order half in the first); float and double parameters, one fp register. Parameters are assigned to registers starting with the lowest volatile register through the highest volatile register of the required kind (gp or fp).</p>

<p>Any additional parameters are passed on the stack in a parameter spill area of the caller's stack frame. The first spilled parameter occupies the lowest memory slot. Slots are filled in the order that parameters are spilled.</p>

<p>An int, or object reference, result is returned in the first volatile gp register; a float or double result is returned in the first volatile fp register; a long result is returned in the first two volatile gp registers (low-order half in the first);</p>

<h4><a name="VMConventions-Methodprologueresponsibilities"></a>Method prologue responsibilities</h4>

<p>(some of these can be omitted for leaf methods):</p>
<ol>
	<li>Execute a stackoverflow check, and grow the thread stack if necessary.</li>
	<li>Save the caller's next instruction pointer (callee's return address, from the Link Register).</li>
	<li>Save any nonvolatile floating-point registers used by callee.</li>
	<li>Save any nonvolatile general-purpose registers used by callee.</li>
	<li>Store and update the frame pointer FP.</li>
	<li>Store callee's compiled method ID</li>
	<li>Check to see if the Java<a href="http://docs.codehaus.org/display/RVM/Trademarks" title="Trademarks">™</a> thread must yield the Processor (and yield if threadswitch was requested).</li>
</ol>


<h4><a name="VMConventions-Methodepilogueresponsibilities"></a>Method epilogue responsibilities</h4>

<p>(some of these can be ommitted for leaf methods):</p>
<ol>
	<li>Restore FP to point to caller's stack frame.</li>
	<li>Restore any nonvolatile general-purpose registers used by callee.</li>
	<li>Restore any nonvolatile floating-point registers used by callee.</li>
	<li>Branch to the return address in caller.</li>
</ol>


<h2><a name="VMConventions-Linux%2Fx8632VMConventions"></a>Linux/x86-32 VM Conventions</h2>

<p>This section describes register, stack, and calling conventions that apply to Jikes RVM on Linux<a href="http://docs.codehaus.org/display/RVM/Trademarks" title="Trademarks">®</a>/x86-32.</p>

<h3><a name="VMConventions-Registerconventions"></a>Register conventions</h3>

<ul>
	<li><b>EAX:</b> First GPR parameter register, first GPR result value (high-order part of a long result), otherwise volatile (caller-save).</li>
	<li><b>ECX:</b> Scratch.</li>
	<li><b>EDX:</b> Second GPR parameter register, second GPR result value (low-order part of a long result), otherwise volatile (caller-save).</li>
	<li><b>EBX:</b> Nonvolatile.</li>
	<li><b>ESP:</b> Stack pointer.</li>
	<li><b>EBP:</b> Nonvolatile.</li>
	<li><b>ESI:</b> Processor register, reference to the Processor object for the current virtual processor.</li>
	<li><b>EDI:</b> Nonvolatile. (used to hold JTOC in baseline compiled code)</li>
</ul>


<h3><a name="VMConventions-Stackconventions"></a>Stack conventions</h3>

<p>Stacks grow from high memory to low memory. The layout of the stackframe appears in a block comment in <tt>ia32/StackframeLayoutConstants.java</tt>.</p>

<h3><a name="VMConventions-CallingConventions"></a>Calling Conventions</h3>


<h4><a name="VMConventions-Atthebeginningofcallee%27sprologue"></a>At the beginning of callee's prologue</h4>

<p>The first two areas of the callee's stackframe (see above) have been established. ESP points to caller's return address. Parameters from caller to callee are as mandated by <tt>ia32/RegisterConstants.java</tt>.</p>

<h4><a name="VMConventions-Aftercallee%27sepilogue"></a>After callee's epilogue</h4>

<p>Callee's stackframe has been removed. ESP points to the word above where callee's frame was. The framePointer field of the Processor object pointed to by ESI points to A's frame. If B returns a floating-point result, this is at the top of the fp register stack. If B returns a long, the low-order word is in EAX and the high-order word is in EDX. Otherwise, if B has a result, it is in EAX.</p>

<h2><a name="VMConventions-OSXVMConventions"></a>OS X VM Conventions</h2>


<h3><a name="VMConventions-CallingConventions"></a>Calling Conventions</h3>

<p>The calling conventions we use for OS X are the same as those listed at:</p>

<p><a href="http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/MachORuntime.pdf">http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/MachORuntime.pdf</a></p>

<p>They're similar to the Linux PowerPC calling conventions. One major difference is how the two operating systems handle the case of a long parameter when you only have a single parameter register left.</p>

				    
                    			    </td>
		    </tr>
	    </table>
	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
			<tr>
				<td height="12" background="http://docs.codehaus.org/images/border/border_bottom.gif"><img src="images/border/spacer.gif" width="1" height="1" border="0"/></td>
			</tr>
		    <tr>
			    <td align="center"><font color="grey">Document generated by Confluence on Jul 04, 2010 19:57</font></td>
		    </tr>
	    </table>
    </body>
</html>